src/main/java/com/salemale/domain/search/service/NearbyItemSearchServiceImpl.java (1)

45-55: Consider using Set<Long> instead of List<Long> for blocked seller IDs.

Using List.contains() inside the mapping loop is O(n) per item, which can degrade performance when the block list is large. ItemService already uses Set<Long> for this purpose (see Lines 381-388 in ItemService.java). Using a Set here would provide O(1) lookup and maintain consistency across services.

         // 내가 차단한 판매자 ID 목록
-        List<Long> blockedSellerIds =
-                blockListRepository.findBlockedUserIds(userId);
+        Set<Long> blockedSellerIds = new HashSet<>(
+                blockListRepository.findBlockedUserIds(userId));

         Page<Item> page = itemRepository.findNearbyItems(ItemStatus.BIDDING.name(), lat, lon, km, pageable);

         return page.map(item -> {
             boolean blockedSeller =
                     blockedSellerIds.contains(item.getSeller().getId());
             return ItemConverter.toAuctionListItemDTO(item, blockedSeller);
         });

Add import:

import java.util.HashSet;
import java.util.Set;

src/main/java/com/salemale/domain/item/converter/ItemConverter.java (1)

171-213: Reduce code duplication by delegating to the new overload.

The two toAuctionListItemDTO methods share identical logic except for the blockedSeller field. To improve maintainability and follow DRY principles, consider having the original method delegate to the new one.

     public static AuctionListItemDTO toAuctionListItemDTO(Item item) {
-        // 전체 이미지 사용
-        List<String> imageUrls = item.getImages().stream()
-                .map(ItemImage::getImageUrl)
-                .collect(Collectors.toList());
-
-        return AuctionListItemDTO.builder()
-                .itemId(item.getItemId())
-                .title(item.getTitle())
-                .imageUrls(imageUrls)
-                .currentPrice(item.getCurrentPrice())
-                .bidderCount(item.getBidCount())
-                .endTime(item.getEndTime())
-                .viewCount(item.getViewCount())
-                .itemStatus(item.getItemStatus().name())
-                .startPrice(item.getStartPrice())  // 시작가
-                .createdAt(item.getCreatedAt())    // 시작날짜
-                .build();
+        return toAuctionListItemDTO(item, false);
     }

src/main/java/com/salemale/domain/item/controller/ItemController.java (1)

188-205: Potential redundant call and overly broad exception handling.

Two observations:

1. Redundant getCurrentUserId call: loginUserId is already extracted (lines 190-195), but for RECOMMENDED status, getCurrentUserId is called again (line 199). Consider reusing loginUserId with a null check.

2. Broad exception suppression: Catching all Exception types could hide unexpected errors. Consider catching only the specific authentication exception type.

         // 로그인 안 했으면 null
         // 로그인 했으면 userId
         Long loginUserId = null;
         try {
             loginUserId = currentUserProvider.getCurrentUserId(request);
-        } catch (Exception e) {
+        } catch (GeneralException e) {
             // 비로그인 요청이면 그대로 null 유지
         }

         // 추가: RECOMMENDED 상태일 때는 별도 처리
         if (status == AuctionStatus.RECOMMENDED) {
-            Long userId = currentUserProvider.getCurrentUserId(request);
+            if (loginUserId == null) {
+                throw new GeneralException(ErrorStatus.USER_NOT_FOUND);
+            }
-            AuctionListResponse response = itemService.getRecommendedAuctionList(userId, pageable);
+            AuctionListResponse response = itemService.getRecommendedAuctionList(loginUserId, pageable);
             return ResponseEntity.ok(ApiResponse.onSuccess(response));
         }

src/main/java/com/salemale/domain/search/service/KeywordItemSearchServiceImpl.java (1)

174-202: Review in-memory filtering impact on pagination.

The nearby search applies category, price, and POPULAR filters in memory after DB pagination (lines 175-183). This can result in fewer items being returned than the requested page size, leading to inconsistent pagination behavior. The comment at line 191 states "페이지네이션 유지" (maintain pagination) and claims only sorting is adjusted, but the code clearly performs filtering as well.

While this appears to be pre-existing logic (only the DTO mapping changed in this PR), consider refactoring to apply these filters at the repository level to maintain accurate pagination, or adjust the comment to reflect the actual behavior.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro